(19) 



(12) 




(43) Date of publication: 

22.11.2000 Bulletin 2000/47 



Europalsch s Patentamt 
European Patent Office 
Office eur peen des brevets (11) EP 1 054 322 A2 

EUROPEAN PATENT APPLICATION 

(51) Int. CL 7 : G06F 9/46 



(21) Application number: 00304271 .0 

(22) Date of filing: 19.05.2000 



(84) Designated Contracting States: 

AT BE CH CY DE DK ES Fl FR OB GR IE fT LI LU 
MCNLPTSE 

Designated Extension States: 
AL LT LV MK RO SI 

(30) Priority: 21.05.1999 JP 14091499 



(71) Applicant: Hitachi, Ltd. 
Chlyoda-ku, Tokyo 101-8010 (JP) 

(72) Inventors: 

• Endo, Yoshlnorl 

Mito-shi, Ibarakl 310-0844 (JP) 

• Nakamura, Kozo 
Hltachiota-shl, Ibarakl 313-0004 (JP) 



• Kamiwakl, Tadashl 
Naka-gun, Ibarakl 319-1111 (JP) 

• Salto, Masahlko 

Hltachl-shl, Ibarakl 319-1225 (JP) 

• Ohno, Hlroshl 

Hltachl-shl, Ibarakl 319-1225 (JP) 

• Nakamura, Tomoakl ^ .;^ WS 3fti* ! 
Hltachinaka-shl, Ibarakl 312-0052 (JP) 

(74) Representative: 

Hackney, Nigel John et al 

Mewbum Ellis, 

York House, 

23 Kingsway 

London WC2B 6HP (GB) 



(54) Computer system with multiple operating system operation 



CM 

< 

CM 
CM 
CO 

in 



(57) A computer system is provided with a scheme 
to making the input and output device provided in a 
computer in common for a plurality of operating system, 
in a multiple operating system control unit operating a 
plurality of mutually distinct operating systems on one 
computer system. The computer system includes a plu- 
rality of operating systems, and OS switching unit for 
switching a plurality of operating systems. The OS 
switching means makes reference to a preferential inter- 
rupt table on the basis of an interrupt factor for switching 
to corresponding operating system and calls interrupt 
processing means incorporated in the operating sys- 
tem. 
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D scription 



roooil The present invention is directed to a data 
nputting and outputting method to a peripheral devices 
In a computer system operating with a plurality of oper- 
ating systems on a single processor, and is related to a 
control method for using the same peripheral dev.ce in 
common for a plurality of operating systems in common. 
Description of the Related Art 

mo021 In normal computer, one operating system is 
operated. The operating system manages resources of 
the computer, such as a processor, a memory and a 
secondary storage device and performs resource 
scheduling so as to operate the computer efficiently. 
Here, there are various kinds of operating systems. One 
is superior in batch process, another is superior in GU 
such as an office work, the other is superior in a rea 
time process. In order to bring out feature of a plurality 
of operating systems, there is a needs to execute a plu- 
rality of operating systems simultaneously on the single 
——computer. For example, in case of a large size compu- 
ter it has been demanded to operate an operating sys- 
tem executing an on-line process associated wrth an 
actual business or an operating system for develop- 
ment Also, it is demanded to operate an operating sys- 
tem provided with GUI and an operating system 
superior in real time characteristics. 
100031 As a mechanism for operating a plurality of 
operating systems on one computer, there is a virtual 
computer system (OS Series Vol. 1 1 , VM, Tomoo OKA- 
ZAKI Kyoritsu Shuppan K.K.) which has been realized 
in a large size computer, In the virtual computer system. 
A virtual computer control program occupies and man- 
ages all hardware and make it virtual to form the virtual 
computer. A control portion forming the virtual computer 
makes a physical memory, an input and output dev.ce, 
an external interrupt and so forth virtual. For example, 
divided physical memory behave as if a physical mem- 
ory starting from zero address for the virtual computer. 
Unit numbers identifying the input and output device are 
also made virtual. Furthermore, by dividing a storage 
region of a magnetic disk to realize even making a mag- 
netic disk drive virtual. 

ro004] On the other hand, as a technology for pro- 
viding interface for a plurality of operating system in one 
computer, there is a micro kernel. In the micro kernel, 
an operating system server for providing operating sys- 
tem function to be shown to the user on micro kernel, is 
ectabli*hed. The user utilizes a resource of the compu- 
ter via the server. By providing servers for each operat- 
ing system, it becomes possible to provide various 
operating system environments for the user. 
f0005] For example, in case of a vehicle mounting 
navigation system, importance is given for a real time 
characteristics for instantly responding to var.at.on of 
external environment and a reliability as to not to stop 
the system. Therefore, a real time operating system 
(r al time OS) having a compact module construction 



with high interruption response is frequently used. How- 
ever the real time OS cannot be said to have superior 
interface wrth a person, while it gives importance for real 
time characteristics and reliability. On the other hand, 
s an office work operating system (general purpose OS) 
to be typically used in typical personal computer (PC) is 
provided an environment for directly operating a display, 
such as GUI to provide superior human interface. 
Therefore, a demand to use a user interface of the gen- 
10 eral purpose OS even in the field where the real time 
OS has been used conventionally, is growing. However, 
since the general purpose OS takes interactive process 
wrth the person, it gives greater importance for a 
throughput of the process rather than response charac- 
, 5 teristics to interrupt process and thus is possible to exe- 
cute a process with maintaining interrupt inhibiting 
condition for a relatively long period. On the other hand, 
in comparison with the real time OS having compact 
construction, it cannot be said comparable in reliability. 
20 [0006] However, similarly to a system for operating 
a plurality of virtual computers (operating systems) in 
parallel on the large size computer, if the general pur- 
pose OS and the real time OS can be operated in the 
same computer system in a build-in system to switch 
25 the operating system as required, it may be possible to 
achieve both of superior used interface and real time 
characteristics and reliability. Considering improvement 
of performance of the microprocessor, operating a plu- 
rality of operating systems in one computer system has 
30 not been a technology permitted only the large size 
computer. 

[0007] While it is required to be adapted for multiple 
users in the large computer, whereas a built-in equip- 
ments may be required to be at least adapted to a single 
35 user in the build-in equipments. Therefore, when the 
real time OS and the general purpose OS are operated 
in the single system, a simplest operating system 
switching method in consideration of importance of 
respective operating systems, if a process to be exe- 
40 cuted in the real time OS is present, to operate the real 
time OS preferentially and to operate the general pur- 
pose OS when the task to be executed on the real time 
OS is not present, is applicable. In such switching 
method the operating systems, a method of switching of 
as the operating system by discriminating the interrupt 
number generated, by statically determining the operat- 
ing system receiving the interrupt demand per input and 
output devices in inputting and outputting with the 
peripheral device. For example, when the foregoing 
so method is applied to the vehicle mounted navigation 
system the operating system is switched so that an 
interrupt handler of the real time OS is actuated for the 
interrupt from the sensor necessary for determining the 
position and an interrupt handler of the general purpose 
55 OS is actuated for interrupt from a display controller. 
However, since the reliability of the general purpose OS 
is not necessarily high, in the shown application, proc- 
ess of the general purpose OS is stopped, the user 
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interface becomes impossible to use to lower reliability 
of the overall vehicle mounted navigation system. In 
order to solve the foregoing problem, the process may 
be divided to assign the process which is desired to 
never be interrupted to the real time OS side and to 5 
assign the process permitting interruption to the general 
purpose OS side. However, if the input and output proc- 
ess for the user interface is process on the side of the 
real time OS, introduction of the general purpose OS 
superior in user interface becomes meaningless. There- 10 
fore, it becomes essential to permit use of the input and 
output device from a plurality of operating systems, 
namely from both of the general purpose OS and the 
real time OS. Therefore, a problem is encountered in 
that it is insufficient to statically determine the operating 75 
system to execute the input and output process from the 
interrupt number as set forth above, and cannot be 
applicable for practical use. 

[0008] An object of the present invention to provide 
a scheme to making the input and output device pro- 20 
^vided in a corrfputer in common fof aTpluralftjfS^ 
ing system, in a multiple operating system control unit 
operating a plurality of mutually distinct operating sys- 
tems on one computer system. 

[0009] In order to accomplish the above-mentioned 25 
object, According to the first invention, a computer sys- 
tem including a plurality of operating systems, and an 
OS switching means for switching a plurality of operat- 
ing systems, characterized in that said OS switching 
means makes reference to a preferential interrupt table 30 
on the basis of an interrupt factor for switching to corre- 
sponding operating system and calls interrupt process- 
ing means incorporated in said operating system for 
making the input and output device provided in the com- 
puter system in common for a plurality of operating sys- 35 
terns.. 

[0010] According to the second invention, a compu- 
ter system having a plurality of operating systems and 
OS switching means for switching a plurality of operat- 
ing systems, characterized by including peripheral 40 
device to be common for a plurality of operating sys- 
tems, data inputting and outputting server for inputting 
and outputting data with the peripheral device to be 
used in common, providing in one of the operating sys- 
tems, data inputting and outputting client for inputting as 
and outputting data with the operating system other 
than said one operating system, requesting inputting 
and outputting data to said data inputting and outputting 
server and executing inputting and outputting of data by 
receiving a result of data inputting and outputting with 50 
the peripheral server in the data inputting and outputting 
server. 

BRIEF DESCRIPTION OF THE DRAWINGS 

55 

[0011] The present invention will be understood 
more fully from the detailed description given hereinaf- 
ter and from the accompanying drawings of the pre- 



ferred embodiment of the present invention, which, 
however, should not be taken to be limitative to the 
invention, but are for explanation and understanding 
only. 

[001 2] In the drawings: 

FIG. 1 is an illustration showing a system construc- 
tion in the first embodiment of the present invention; 
FIG. 2 is an illustration showing a hardware con- 
struction of a computer system; 
FIG. 3 is an illustration showing a status register in 
the case where an interrupt level mask function is 
provided; 

FIG. 4 is an illustration showing a status register i n 
the case where an individual interrupt mask func- 
tion is provided. 

FIG. 5 is a first illustration showing a detail of an 

interrupt processing program; 

FIG. 6 is an illustration showing a construction of 

the jnterrupt address table; ^_ 

^ FlG. 7lsanllTustration showing a construction of a 

preferential interrupt table; 

FIG. 8 is an illustration showing a process flow of an 
OS context switch module; 

FIG. 9 is a first illustration showing a process flow of 
a common interrupt handler; 

FIG. 1 0 is a first illustration showing a process flow 
of an interrupt handler; 

FIG. 11 is an illustration showing a construction of 
an input and output panel of a vehicle mounted nav- 
igation system; 

FIG. 12 is an illustration showing a construction of a 
switch table; 

FIG. 13 is a second illustration showing the process 
flow of the common interrupt handler; 
FIG. 14 is a second illustration showing the syst m 
construction in the second embodiment of the 
present invention; 

FIG. 15 is a third illustration showing the process 
flow of the common interrupt handler; 
FIG. 16 is a second illustration showing the process 
flow of the interrupt handler; 

FIG. 17 is a third illustration showing the process 
flow of the interrupt handler; 

FIG. 18 is a first illustration showing a detail of an 

input and output processing program; 

FIG. 19 is a second illustration showing a detail of 

an input and output processing program; 

FIG. 20 is an illustration showing a flow of re-writinc: 

a preferential interrupt table; and 

FIG. 21 is an illustration showing a construction of a 

system in which the present invention is applied to 

a graphic display device. 

[0013] The present invention will be discussed 
hereinafter in detail in terms of the preferred embodi- 
ment of the present invention with reference to the 
accompanying drawings. In the following description, 
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numerous specific details are set forth in order to pro- 
vide a thorough understanding of the present invention. 
It will be obvious, however, to those skilled in the art that 
the present invention may b practiced without these 
specific details. In other instance, well-known structure 
are not shown in detail in order to avoid unnecessary 
obscurity of the present invention. 
[001 4] Embodiments of a computer system accord- 
ing to the present invention will be discussed with refer- 
enc to the drawings. 

[0015] An overall construction in the first embodi- 
ment of the computer system according to present 
invention is illustrated in Fig. 1. Normally, a computer 
system is constructed with a processor 100, a memory 
101, an input and output control device 102, a display 
104, a switch 105, a sensor 106 and so forth. The proc- 
essor 100, the memory 101 and the input and output 
control device 102 are connected by a processor bus 
103. The processor 100 is a microprocessor for operat- 
ing a plurality of operating systems. The memory 101 
stores operating systems -1t6"and^1^7, task-programs - 
110 to 115 operated on respective operating systems, 
input and output driver programs 120 and 121 for 
respective operating systems, interrupt handler pro- 
grams 122 and 123, and inter-OS control function pro- 
gram 124. These programs are read from the memory 
101 and executed by the processor 100. 
[0016] The input and output control device 102 is 
connected with a display 104 as an image display 
d vice, a switch 105 for receiving a command from a 
user, a sensor 106 for detecting variation of peripheral 
environment and so forth. On the other hand, upon real- 
izing a factory/plant controlling or built-in computer sys- 
tem, a network 109 may be connected to the input and 
output control device 102. To the network 109, an input 
and output equipment, such as a communication equip- 
ment and so forth, is connected. It should be noted that 
among input and output devices 1 04 to 1 06 connected 
to the input and output control device 1 02, any one or all 
of the input and output devices may be omitted in some 
system configuration. Furthermore, wide variety of input 
and output devices may be connected for notifying com- 
pletion of input and output operation and so forth. In Fig. 
1, while the interrupt signal line 108 and the processor 
bus 103 are illustrated as separate devices for the pur- 
pose of illustration, the interrupt signal line is a part of 
the processor bus 103, in practice. Within the processor 
100, a timer device 107 is provided to cause an internal 
interrupt per a given period. An interrupt caused by the 
tim r device 107 is used for time measurement of the 
operating system or the like. 

[0017] The processor 100 is provided with a func- 
tion for masking an external interrupt command input 
through the interrupt signal line 108 and an internal 
interrupt command from the timer device 107 and so 
forth. The masking of interrupt is a function for delaying 
a particular interrupt until masking of interrupt is 
released by a program. Typically, as the interrupt mask- 



ing functions, the following three kinds are present. 

(1) All Interrupt Mask: All of interrupts are masked. 

(2) Individual Interrupt Mask: Each individual inter- 
5 rupt is masked. 

(3) Interrupt Level Mask: Level is set for each inter- 
rupt for masking interrupt lower than or equal to a 
designated level. 

10 [0018] Depending upon kind of the processor 100, 
interrupt masking of a combination of the foregoing (1) 
and (2) or a combination of (1) and (3) may be provided, 
frequently. When the processor having the latter combi- 
nation is employed, the interrupt level is assigned 

is depending upon importance and minimum response 
period of the corresponding input and output device. For 
example, an interrupt from a network requiring a short 
response period is set at higher level than that of the 
interrupt from the switch 105, the storage device 106 

20 and so forth. 

«=: ^;ooi9] " In the shown embodiment; discussion will be 
given for the case where two operating systems 116 
and 117 are present in the computer system. The oper- 
ating systems 116 and 117 execute tasks 110 to 115 

25 using memory assigned for each operating system and 
a resource of the processor. While Fig. 1 shows an 
example where number of operating systems is two and 
total number of the tasks is six, it is possible to load the 
operating systems or tasks in greater or smaller number 

30 than that illustrated. While the shown embodiment does 
not consider dynamic variation of number of the operat- 
ing systems, it is possible that each operating system 
dynamically generate and delete the takes. Further- 
more, in the shown embodiment, it is assumed that the 

35 operating system 1 16 is the general purpose OS which 
is adapted for word processing, data processing and so 
on and the operating system 117 is the real time OS 
which requires real time response, such as computer 
games, navigation system and so forth. However, th 

40 technology descried in the present invention is applica- 
ble for any kind of the operating systems. The tasks 110 
to 1 12 are tasks to be executed by the general purpose 
OS, and the tasks 1 13 to 1 15 are real time tasks to be 
executed by the real time OS. Also, the following discus- 

45 sion will be given with an assumption that preferential 
order of interrupt of the real time OS is higher than that 
of the general purpose OS in order to guarantee a 
response period in the real time OS. In the assumption, 
when any one of the tasks of the real time OS is in exe- 

so cution, the real time OS 1 16 uses the resource of the 
processor. When all of the tasks are in idling condition 
or waiting condition, the context is switched to the gen- 
eral purpose OS so that the general purpose OS uses 
the resource of the processor. 

55 [0020] The inter-OS control function 1 24 is provided 
for operating the general purpose OS 116 and the real 
time OS 1 17 in cooperation with each other. The inter- 
OS control function 124 includes a common memory 
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125 accessible from both of the general purpose OS 
and the real time OS, an inter-OS communication func- 
tion 1 26 for performing transfer of message between the 
general purpose OS and the r al time OS, an OS con- 
text switching function 127 for switching executing envi- 5 
ronment of the general purpose OS and the real time 
OS, a common interrupt handler 128 for distributing the 
generated interrupt commands to respective operating 
systems, and a preference management table 129 stor- 
ing the operating systems corresponding to the interrupt 10 
demands or interrupt start addresses. 
[0021] The common memory 125 intends the real- 
ize high speed data exchange between the operating 
systems and can read and write out and in by both of 
the general purpose OS and the real time OS. Here, in is 
order to avoid conflict of data, it is desirable to exclu- 
sively access the common memory using a semaphore 
function. The inter-OS communication function 126 pre- 
pares a message queue corresponding to respective 
operating system for transferring the message between 20 
respective operating systems; The "common interrupf" 
handler 128 initially call upon generation of the interrupt 
demand to determine the operating system per interrupt 
number stored in the preferential interrupt table 129 to 
call the corresponding interrupt handler 122 and 123. 25 
The OS context switching function 127 switches context 
as judged that switching of the operating system is nec- 
essary in response to the interrupt demand or calling of 
inter-OS control function. The interrupt management 
table 129 stores the operating system information, in 30 
which the interrupt handler called per interrupt number 
belongs, and start address information of the interrupt 
handler per operating system. In the conventional 
method, the interrupt management table 129 statically 
determines upon starting up of the system. Therefore, 35 
the content could not be re-written during system oper- 
ation. In the shown system, by providing re- writing 
means for re-writing the interrupt management table 
129 even during system operation, common use of one 
input and output device with a plurality of operating sys- 40 
terns is enabled. 

[0022] The operating systems 116 and 1 1 7 has the 
input and output drivers 120 and 121 for processing 
data input and output with the input and output device 
and the interrupt handlers 122 and 123 for receiving 45 
interrupt demand from the input and output devices. 
The interrupt handlers 122 and 123 are called from the 
common interrupt handler 1 28. One of the interrupt han- 
dlers 122 and 123 called by the common interrupt han- 
dler 128 executes interrupt processing program defined so 
by the user. The input and output drivers 120 and 121 
provide interfaces for controlling the input and output 
devices and provide functions for inputting and output- 
ting data by reading and writing data from and in the 
input and output device and controlling the input and 55 
output device. Re-schedul rs 1 18 and 119 initiate oper- 
ation in the case where task has to be switched associ- 
ating with generation, deletion, stopping, and restoring 



of task, external interrupt or internal interrupt. The re- 
scheduler stores execution environment (program coun- 
ter, status register, gen ral purpose register and so 
forth) of the task executed immediately before in a task 
management table, determines to be newly executed, 
takes out the execution environment from the task man- 
agement table to set in respective registers to execute 
the selected task. 

[0023] Fig. 2 shows an example of internal con- 
struction of the processor premised in the present 
invention. A cache memory 130 is a buffer storage 
device for temporarily storing data or instruction on the 
memory 101. CPU 131 is an arithmetic circuit and 
sequentially executes instructions present on the mem- 
ory 101 or the cache memory 130. Upon execution of 
the instruction, a general purpose register 132 tempo- 
rarily storing the result of arithmetic operation, a pro- 
gram counter 133 for storing an execution instruction 
address and a status register 1 34 for storing execution 
_status. The cache memory J 30. CPU 131, the general 
purpose register 132, the program counter 133, the sta- 
tus register 1 34 are connected with each other by a data 
bus 135 for transferring data and an address bus 136 
performing address designation. 

[0024] The interrupt signal line 108 and the timer 
device 107 are connected to an interrupt controller 137. 
The interrupt controller 137 has a function for generat- 
ing interrupt state signal 138 with respect to CPU 130. 
The interrupt state signal 138 is a signal line indicating 
what kind of interrupt is currently occurred on the proc- 
essor 100. Normally, the status register 134 has infor- 
mation relating to current interrupt mask to determine 
whether interrupt designated by the interrupt status sig- 
nal 138 is accepted or not. Upon accepting interrupt, the 
interrupt controller 137 re-writes the program counter 
1 33, the status register 1 34 and so forth to execute cor- 
responding interrupt processing program. 
[0025] An example of structure of the status register 
134 is shown in Fig. 3. Here, an example of the case 
where all interrupts masking function and interrupt level 
masking function are provided in the processor 100. In 
the example of Fig. 3, the status register 134 has an 
interrupt block bit 140 and an interrupt mask level field 
141. When the interrupt block bit 140 is ON, all inter- 
rupts to the processor 100 is masked. The interrupt 
mask level field 141 shows the current interrupt mask 
level value, and interrupt level lower than or equal to this 
level is not accepted. In case of the example shown in 
Fig. 3, the interrupt mask level field 141 has a length c ! 
four bit length. Therefore, sixteen kinds in total of the 
mask levels can be designated (normally, the interrupt 
level 0 represent "interrupt does not occur", and thus fif- 
teen kinds in practice). By varying the bit number of the 
interrupt mask level fieid 141, kind of the interrupt level 
to accept can be increased and decreased. 
[0026] Fig. 4 shows the status register 134 for the 
case where the processor 100 is provided with ail inter- 
rupt masking function and individual interrupt masking 
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function. In this example, the status register 134 is con- 
structed with two registers (an execution status register 
142 and in interrupt masking register 143). Similarly to 
Fig. 3, the interrupt block bit 140 in the execution status 
register 142 is provided. Interrupt mask bits 144 to 147 
in the interrupt masking register 143 correspond to 
interrupt separately. When any one of the interrupt 
mask bits is turned ON, reception of the corresponding 
interrupt is prohibited. The example of status register 
shown in Fig. 3 is special example of the status register 
134 of Fig. 4. For example, a state where only interrupt 
mask bit 144 is ON, is referred to as level 1. When two 
of th interrupt mask bits 144 and 145 are ON, the state 
is referred to as level 2. When three of the interrupt 
mask bits 140 to 146 are ON, the state is referred to as 
level 3, ... for establishing correspondence. Therefore, in 
the following disclosure, the status register 134 will be 
discussed to have the construction shown in Fig. 4. 
[0027] In general processor, upon reception of 
interrupt the interrupt block bit 140 is automatically re- 
writfeh^to ON'-by hardware.- As^^-m 
processing program re-writes the interrupt block bit 140 
to OFF to enable accepting interrupt. On the other hand, 
it is also possible to temporarily re-write the contents of 
the interrupt block bit 140 and the interrupt mask regis- 
ter 143 by the operating system and the task to place 
the system to wait for reception of a particular interrupt. 
The interrupt masking function is used for realizing 
exclusive control and avoiding occurrence of the same 
interrupt during execution of interrupt process. 
[0028] Fig. 5 shows detail of the interrupt handlers 
1 22 and 1 23, the common interrupt handier 1 28, the OS 
context switching function 127 and the interrupt man- 
agement table 129. 

[0029] The interrupt handler 122 and 123 have 
interrupt stacks 151 and 153 respectively as regions for 
storing register and so forth upon occurrence of inter- 
rupt and storing a temporary parameter. The interrupt 
stacks 151 and 153 are provided for storing register 
valu immediately before occurrence of interrupt and 
returning the register value to the original value after 
completion of the interrupt process, upon occurrence of 
interrupt. Some kind of processor 100 to be used, a 
function to automatically switch the register upon occur- 
rence of interrupt and to return to the register before 
switching after the interrupt process. However, in con- 
sideration of the system permitting multiple interrupts, 
stack becomes necessary even in using such hardware 
(when interrupt having higher preference occurs during 
process of interrupt, the newly occurred interrupt proc- 
ess is executed preferentially, and then has to return to 
the original interrupt process). The interrupt handlers 
122 and 123 has interrupt stack pointers 150 and 152 
as pointers showing what region is used in the interrupt 
stacks 151 and 153. The interrupt handlers 122 and 123 
store execution environment (register and so forth) 
using the interrupt stack pointer to execute necessary 
interrupt proc ss. After completion of the interrupt proc- 



ess, the execution environment before occurrence of 
interrupt is resumed to continue originally executed pro- 
gram. 

[0030] The common interrupt handler 128 has a 

5 function for distributing occurred interrupt to the inter- 
rupt handlers 122 and 123. Therefore, the common 
interrupt handler 128 has an executing OS storage 
parameter 154 as a region for storing which of the gen- 
eral purpose OS 116 and the real time OS 1 17 is the 

w operating system currently executed. For example, 
assuming that the general purpose OS is in execution at 
the time of Fig. 5, "general purpose OS" is stored in the 
executing OS storage parameter 154, in this case. Of 
course, since it is quite inefficient to store the character 

is string "general purpose OS" in the executing OS stor- 
age parameter 1 54, it may be stored in a form of integer, 
such that 0 is stored if the general purpose OS is in exe- 
cution and 1 is stored if the real time OS is in execution. 
[0031] The interrupt management table 129 has a 

20 preferential interrupt table 1 56 indicating which interrupt ^ 
„ ---handler of one-of the*>perating system is to be actuated^ 
and an interrupt address table 155 indicating a start 
address of the interrupt handlers included in respective 
operating systems. The preferential interrupt table 156 

25 is constructed with a correspondence table indicating 
which of the operating systems processes the individual 
interrupt as shown in Fig. 7, for example to request 
process to the interrupt handler of the operating system, 
for which the flag 1 is stored. Furthermore, for interrupt 

30 from the input and output device common for a plurality 
of operating systems, flag is set to 1 , and not common 
interrupt, flag 0 is stored. In the shown embodiment, 
assuming that sixteen kinds of interrupt factors are 
present, the interrupt correspondence table 156 is 

35 formed with sixteen entries (IRQ#0 to IRQ#15). In this 
disclosure, it is premised a method for storing a flag in a 
preferential driver table 160, it may be realized by any 
method by storing some identifiable information. The 
interrupt address table 155 is a table holding start 

40 address of the interrupt handler included in each oper- 
ating system as shown in Fig. 6, for example. 
[0032] in the present invention, in order to achieve 
the object to use one input and output equipment for a 
plurality of operating systems in common, a mechanism 

45 for dynamically varying the operating system to be actu- 
ated from the interrupt demand received by the com- 
mon interrupt handier 128. The content of the 
preferential interrupt table 156 is updated depending 
upon the user operation and use condition of the input 
50 ana output equipment. The common interrupt handiei 
1 28 operates to call interrupt handler according to the 
content of the preferential interrupt table 156. In further 
detailed discussion, the common interrupt handler 128 
make reference to the executing OS storage parameter 
55 1 54 to make judgment of the kind of the currently exe- 
cuted operating system. If the kind of the operating sys- 
tem does not match with the operating system to be 
assigned obtained from the preferential interrupt table 
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1 54, switching of the operating system is requested to 
the OS context switch module 127. Upon completion of 
switching of the operating system or if the operating sys- 
tem matches and thus switching is unnecessary, proc- 
ess is requested to the interrupt handler of the 5 
corresponding operating system. It should be noted that 
the executing OS storage parameter 1 54 is made refer- 
ence to even from the OS context switch module 127. 
The internal structure having respective modules in the 
inter-OS control function program, is not limited to that 10 
occupied by individual modules but can be common in 
respective modules as required. 

[0033] The OS context switch module 127 is actu- 
ated when the operating systems are to be switched as 
a result of calling of the inter-OS control function or is 
occurrence of interrupt In order to switch between the 
operating systems, the region for storing the execution 
environment (namely, register value) is provided. In the 
drawing, as the region for storing the execution environ- 
ment of the general purpose OS in the drawing, a stor- 20 
^age-cbntext for genefarpurpo^e OS T57 is prepared, "~ 
and as a region for storing execution environment of the 
real time OS, a storage context 158 for real time OS is 
prepared. The OS context switch module 127 stores the 
execution environment in the storage context corre- 25 
sponding to the currently executed operating system 
upon switching of the context. Next, the execution envi- 
ronment is read out from another storage context to set 
in the register of the processor 1 00. By this, switching of 
the operating system can be performed. Subsequently, 30 
discussion will be given for process flow of the OS con- 
text switch module 127, the common interrupt handlers 
128 and the interrupt handler 122 among the modules 
shown in Fig. 5. Concerning the interrupt handler 123, 
since it has the same flow as the interrupt handier 1 22, 35 
discussion will be omitted. 

[0034] Fig. 8 is a process flow of the OS context 
switch module 127. The OS context switch module 127 
is called only when the operating systems to be exe- 
cuted are to be switched. Checking whether switching is 40 
necessary or not, is performed before calling. Accord- 
ingly, with reference to the executing OS storage param- 
eter 154, check is performed as to which operating 
systems switching is to be made (process 160). Here, 
upon switching from the general purpose OS 1 1 6 to the 45 
real time OS 1 17, the value of the register being used is 
temporarily stored in the storage context 157 for the 
general purpose OS (process 161). Then, by resuming 
the execution environment from the storage context 158 
for the real time OS to set in the register (process 162), so 
~the real time OS can be re-executed from the temporar- 
ily stored condition. Upon switching from the real time 
OS to the general purpose OS, conversely, the value of 
the register being used is temporarily stored in the stor- 
age context for the real time OS (process 163). Next, 55 
the register 1 57 is resumed from the storage context 
157 for general purpose OS (process 164). In either 
case, finally, the kind of the operating system after 



switching is written in the executing OS storage param- 
eter 154 (process 165). 

[0035] Fig. 9 shows the process flow of the com- 
mon interrupt handler 128. In general, in the computer 
system controlled by a single operating system, all of 
interrupts are once processed by a module called as 
interrupt handler, then is distributed to respective pro- 
grams. However, in case of the computer system ope r- 
ating a plurality of operating system as discussed in the 
shown embodiment, all interrupts are received by the 
common interrupt handler further before to distribute 
the interrupts to the interrupt handlers of the corre- 
sponding operating systems. Upon distribution of inter- 
rupts to respective operating systems, upon occurrence 
of interrupt, it is possible that the operating system other 
than objective for interrupt is in execution. In this case, it 
becomes necessary to switch to the operating system 
corresponding to interrupt. The common interrupt han- 
dler also has such function. 

[0036] The common handler 1 28, at first, takes out 
"the content of the executing OS storage parameter 1 54 
to check whether the operating system currently exe- 
cuted is the general purpose OS 1 1 6 or the real time OS 
117 (process 170), upon occurrence of interrupt. Next, 
reference is made to the preferential interrupt table 156 
to attain which of the interrupt handler of the operating 
systems is to be actuated by the generated interrupt 
demand (process 171). Considering the case where the 
value in the preferential interrupt table 156 shown in Fig. 
6 is used, the operating system corresponding to the 
value can be attained in such a manner that when the 
interrupt IRQ#0 occurs, the real time OS, when the 
interrupt IRQ#1 occurs, the general purpose OS 1 17, ... 
when the interrupt IRQ#15 occurs, the real time OS 
117. Next, check is performed whether the obtained 
interrupt objective operating system matches with the 
operating system in execution or not (process 172). If 
the interrupt demand is not for the currently executed 
operating system, the operating system has to be 
switched once. This switching process is performed by 
requesting switching to the OS context switch module 
127 (process 173). Next, check is performed whether 
the interrupt objective operating system is the gen ral 
purpose OS 1 16 or the real time OS 1 17 (process 174). 
If the object is the general purpose OS 1 1 6, the interrupt 
handler 122 of the general purpose OS is actuated with 
reference to the interrupt address table 155 (process 
175). If interrupt is caused in the real time OS 1 17, ref- 
e fence is made tc the interrupt address 155, similarly, , 
the interrupt handler 123 of the real time as is actuated 
(process 176). In general, when switching of task has to 
be performed in the interrupt process, the interrupt han- 
dler 122 and 123 calls the re-schedulers 1 18 and 1 19 so 
as not to return the control to the common interrupt han- 
dler 128. However, when task switching does not occur, 
the process of the interrupt handler is terminated. At this 
time, the interrupt handlers 122 and 123 returns control 
to the common interrupt handler (discussed later in con- 



7 



13 



EP 1 054 322 A2 



14 



nection with Fig. 10), and the common interrupt handler 
resumes operation from process 177. Process 177 is a 
process for checking whether the operating systems are 
switched upon occurrence of interrupt. When the oper- 
ating system is switched at process 173, the operating s 
system has to be switched again to return to the original 
execution environment. Therefore, request is made to 
th OS context switch module 127 for execution of the 
switching process (process 178). 

[0037] Fig. 10 shows a process flow of the interrupt 10 
handl r of the general purpose OS called from the com- 
mon interrupt handler 128. At first, the register in use is 
temporarily stored in the interrupt stack 151 (process 
180) to execute the interrupt process (process 181). 
Here, check is made whether the operating system is in 75 
re-scheduling or not (namely, whether the re-scheduler 
is in execution of the process or not) (process 182). In 
re-scheduling means that the take to be executed next 
is now in selection, and the task is not actually in execu- 
tion/ Accordingly, when the process of the operating 
sygtgH 1 ranubgjsigipJified^ : fo e.j^cfa^uljgg^n-tbisdease^ 
" can be done again from the beginning. Namely, when 
judgment is made that the re-scheduling is current in 
execution, the temporarily stored register of the inter- 
rupt stack is abandoned (process 187) to actuate the re- 
scheduler 118 from the beginning (process 188). It 
should be noted that there is some cases, in which the 
task in execution is not necessary to be newly selected 
even when interrupt occurs during re-scheduling. In the 
shown system, even in this condition, rescheduling has 
to be performed from the beginning and thus is not effi- 
cient Therefore, it is possible to employ a method to 
register the process (e.g. task initiation, termination and 
so forth) possibly influence for execution of the re- 
scheduler 118, occurring during re-scheduling in a 
queue. In this case, the process registered in queue 
before completion of re-scheduling, is executed aggre- 
gatingly. When this system is employed, it becomes 
unnecessary to re-do re-scheduling executed to the 
mid-way at every occurrence of interrupt. However, after 
aggregatingly executing the process stored in the 
queue, check has to be done again whether re-schedul- 
ing is to be performed or not. It should be noted that, in 
the shown embodiment, discussion will be given with 
the former system for simplification. However, when the 
latter system is employed, a flag indicative of re-sched- 
uling being in process or not or a process queue may be 
prepared. In system call or so forth provided by the 
operating system, the process influencing for execution 
of the re-scheduler 118 is registered ion queue it re- 
scheduling is in execution. Furthermore, during process 
flow of re-scheduler 118, a module to aggregatingly 
executing the processes registered in queue is inserted. 
[0038] When the interrupt handier 1 22 makes judg- 
ment that the re-scheduling is not in execution, the oper- 
ating system should be in execution of certain task at 
that timing. Therefore, at first, check is made wheth r 
task switching is necessary or not (process 183). If 



switching of the task is unnecessary (currently executed 
task is the highest preferential order and is executable), 
the process of the interrupt handler 122 is terminated 
with no change. Therefore, the register value temporar- 
ily stored in the interrupt stack 151 is recovered (proc- 
ess 184) and control is returned to the common 
interrupt handler (process 185). If judgment is made 
that switching of the task is necessary, the value of the 
register temporarily stored in the interrupt stack 161 is 
copied to the task management table (process 1 86), the 
temporarily stored register of the interrupt stack is aban- 
doned (process 187) and then the re-scheduler 118 is 
actuated (process 188). It should be noted that if the 
process 100 is provided with a function to increase and 
decrease the value of the interrupt stack pointer 150 
together with making reference to data on the memory 
101, the processes 186 and 187 can be executed in a 
lump. 

[0039] As set forth above, the method for using the 
input and output device in common for a plurality of 
operating systems by making/fefereRee^o^he^^pf^^ 
tial interrupt table 156 provided in the inter-OS control 
function 124, and actuating the interrupt handler after 
determination of the operating system to be operated. 
25 However, it is possible to occur the case where the 
operating systems cannot be uniformly determined from 
the interrupt number for some input and output device. 
For example, in an input and output panel of a vehicle 
mounted navigation system shown in Fig, 11, for exam- 
30 pie, a switch 105 for inputting a command by the user 
and a display 104 for displaying a result are provided. 
The switch 105 preferably includes a dedicated switch 
190 for real time OS, which is used by only tasks pro- 
vided in the real time OS 1 1 7, a dedicated switch 1 91 for 
35 office work and a common switch 192 which can be 
used in common from the tasks provided in both of th 
operating systems. By providing the dedicated switches 
per operating system, frequently used function can be 
fixedly assigned to the switches to attain a feature to 
40 improve operability. Furthermore, by assigning the func- 
tion to the fixed switch, function name can be displayed 
on the button to improve identifiability. However, provid- 
ing distinct interrupt number per switch is disadvanta- 
geous in viewpoint of constraint of number of interrupt 
45 signal lines and simplification of the hardware. On the 
other hand, by assigning the same interrupt number to 
the switches, it becomes impossible to determine which 
interrupt handlers of the operating systems is to be 
actuated upon depression of the switch. In order to 
50 solve this problem, a switch table 200 is provided in the 
common memory 125 provided in the inter-OS control 
function 124. In the switch table, information of the 
switch to be used by which operating system is stored 
per switch, in Fig. 1 2, in the switch table, "real time OS", 
55 "general purpose OS" and "common" are stored. Of 
course, storing the character string in the table is quite 
inefficient, the information may be stored in a form of 
integer, such as if the operating system is real time OS, 
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0 is stored, if the general purpose OS, 1 is stored, and if 
common, 2 is stored. 

[0040] Next, a process flow of the common interrupt 
handler 1 28 using the input and output d vice in com- 
mon for a plurality of operating systems using the fore- 5 
going switch table 200, will be discussed with reference 
to Fig. 13. The process discussed herein is applicable 
not only for the switch but also for other input and output 
device which require determination which operating 
systems is to be actuated by making judgment of the 10 
content of interrupt. 

[0041] The common interrupt handler 128 makes 
reference to the content of the executing OS storage 
parameter 154 after occurrence of interrupt to check 
whether the current executed operating system is the is 
general purpose OS 1 16 or the real time OS 1 17 (proc- 
ess 210). Next, reference is made to the preferential 
interrupt table 1 56. If the common flag is not set, the 
operating system, to which the occurred interrupt corre- 
sponds, is attained with reference to the preferential 20 
'IffteYrupt table 156 (process 212). If the common flag is 
set, the interrupt objective operating system is deter- 
mined by making judgment of the content of interrupt by 
accessing the input and output device (process 213). 
Here, comparing the content of interrupt and the switch 25 
table 200, when judgment is made that the dedicated 
switch for the real time OS is depressed, the real time 
OS 117 is stored as the interrupt objective OS, and 
when judgment is made that the dedicated switch for the 
general purpose OS is depressed, the general purpose 30 
OS 116 is stored as the interrupt objective OS. When 
judgment is made that the common switch is 
depressed, reference is made to the preferential inter- 
rupt table 156, the operating system, to which the 
occurred interrupt corresponds, is attained. Here, con- 35 
sidering the case where the stored values in the prefer- 
ential interrupt table 1 56 of Fig. 7 and the switch table 
200 of Fig. 12 are used, if IRQ#2 is assigned to switch 
interrupt, when the switch #0 is input, reference is made 
to the real time OS, when the switch #2 is input, refer- 40 
ence is made to the general purpose OS, and when the 
switch #3 is input, since the switch is for common use, 
reference is made to the preferential interrupt table 156 
again to attain the interrupt objective operating system, 
such as the real time OS. 45 
[0042] Next, check is performed whether the inter- 
rupt objective operating system is equal to the operating 
system in execution (process 214). If the occurred inter- 
rupt is not for the currently executed operating system, 
the operating system has to be once switched. This so 
switching process is performed by requesting to the PS 
context switch module 1 27 (process 21 5). Next, check is 
performed whether the interrupt objective operating 
system is the general purpose OS 1 16 or the real time 
OS 117 (process 216). If the object is the general pur- 55 
pose OS 116, the interrupt handler 122 of the general 
purpose OS is actuated with reference to the interrupt 
address table 155 (process 217). If interrupt for the real 



time OS is caused, the interrupt handler 123 of the real 
time OS is actuated with reference to the interrupt 
address table 155, similarly (process 218). In general, 
when the task switching has to be performed by the 
interrupt process, the interrupt handlers 122 and 123 
call the re-schedulers 1 1 8 and 1 1 9 and do not return th e 
control to the common interrupt handler 128. However, 
if task switching is not caused, the process of the inter- 
rupt handler is terminated. At this time, the interrupt 
handlers 122 and 123 return the control to the common 
interrupt handler 128. The common interrupt handier 
1 28 resumes operation from the process 21 9. The proc- 
ess 219 is the process for checking whether the operat- 
ing system is switched upon occurrence of interrupt. 
When the operating system is switched by the process 
215, the operating system has to be switched again to 
return to the original execution environment. Therefore, 
request is again made to the OS context switch module 
127 to execute the switching process (process 220). 
[0043] While . discussion has^ been . given- Jie_rem^ 
above for a method to make the input and output device 
in common in the system where a plurality of operating 
systems are operated on the single computer with refer- 
ence to the preferential interrupt table stored in the 
interrupt management table 129 from the common inter- 
rupt handler provided in the inter-OS control function 
124, the method set for above cannot handle all of the 
cases. For example, in input and output device, such as 
a graphic accelerator or a serial communication, operat- 
ing condition and various operation parameters are set 
from an input and output driver and holes the parame- 
ters and operating condition in the register within the 
hardware. For such input and output device, if the fore- 
going process is simply applied, the input and output 
drivers and interrupt handlers in respective operating 
systems cannot recognize switching of the operating 
systems to attempt to continue process from the condi- 
tion set by the input and output driver of the preceding 
operating system. However, the parameters to be set 
can be normal values only as continued from the value 
finally set by the input and output driver of own operat- 
ing system. It should be clear that the desired operation 
cannot be done if some parameter is written in the input 
and output device between switching of the operating 
system. 

[0044] In order to solve this problem, the present 
invention is characterized by application of a client- 
server model for the input and output process, such as 
the input End output drivers 120 and 121 and the inter- 
rupt handler 122 and 123 provided in each operating 
system as shown in Fig. 14. Namely, with one of the 
input and output process of a plurality of operating sys- 
tems, an input and output process 222 on a server side 
is executed. The server side input and output process 
222 behaves to manag the input and output device 226 
common for a plurality of operating systems to ex cute 
data input and output 225 from th input and output 
driver 121 to the input and output device 226 and to 
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operate for r ceiving the interrupt demand from the 
input and output device 226 by the interrupt handier 
123. Furthermore, receiving a notice of the request from 
th client side input and output process 221 to make 
judgment for the content to perform data input and out- 
put 225 with the input and output device 226, and 
returns the result to the client side input and output 
device 226 as a report of the result. On the other hand, 
th client side input and output device 221 transmits a 
notice 223 of request for data input and output to the 
input and output device 226, to the server side input and 
output device 222, for executing the input and output 
process using the returned report of the result 224. 
Accordingly, the client side input and output process 
does not directly control the hardware of the input and 
output device 226, and the server side input and output 
device constantly manages the input and output device. 
Therefore, no discrepancy will be caused in the operat- 
ing condition. 

[0045] It should be noted that the server side input 
-and-output process 2224s-desirably set in the operating 
system having higher preferential order. In the shown 
embodiment, since it is assumed that the real time OS 
has higher preferential order than the general purpose 
OS, the server side input and output process 222 is pro- 
vided in the real time OS. By providing the server side 
input and output process, the operating system having 
higher preferential order can avoid occurrence of mask- 
ing of the process, such as interrupt demand. Accord- 
ingly, unduly delaying of response upon occurrence of 
the interrupt demand can be avoided to attain a feature 
that missing of data can be avoided. 
[0046] Hereinafter, among the modules shown in 
Fig. 14, process flow of the common interrupt handler 
128 and the interrupt handlers 122 and 123 will be dis- 
cussed. 
[0045] 

[0047] Operational flow of the common interrupt 
handler 1 28 when the client-server model shown in Fig. 
14 is applied for input and output process, will be dis- 
cussed with reference to Fig. 15. It should be noted that 
the basic system construction is similar to Figs. 1 and 5, 
and, in the preferential interrupt table 156, for the inter- 
rupt number of the input and output device to be com- 
mon for a plurality of operating systems, the common 
flag 1 is stored and for the interrupt number of the input 
and output device to be used in the particular operating 
system, the common flag 0 is stored. Furthermore, as 
shown in Fig. 14, the server side input and output proc- 
ess is provided in the real time OS 117 and the client 
side input and output process is provided in the general 
purpose OS. 
[0046] 

[0048] The common interrupt handler 128, at first, 
takes out the content of the executing OS storage 
parameter 154 after occurrence of interrupt to check 
whether the currently executed operating system is the 
general purpose OS 1 16 or the real time OS 1 18 (proc- 



ess 230). Next, reference is made to the preferential 
interrupt table 1 56 (process 231 ). If the common flag is 
not set, the operating system, to which the occurred 
interrupt corresponds, is attained with referenc to the 

5 preferential interrupt table 156 (process 232). If the 
common flag 1 is set, the interrupt objective operating 
system is determined by making judgment of the con- 
tent of interrupt by accessing the input and output 
device (process 233). 

w [0049] Next, check is performed whether the inter- 
rupt objective operating system is equal to the operating 
system in execution (process 234). If the occurred inter- 
rupt is not for the currently executed operating system, 
the operating system has to be once switched. This 

15 switching process is performed by requesting to the PS 
context switch module 1 27 (process 235). Next, check is 
performed whether the interrupt objective operating 
system is the general purpose OS 1 16 or the real time 
OS 1 17 (process 236). If the object is the general pur- 

20 pose OS 1 16, the interrupt handler 122 of the general 
p8Fpe^-OS % 

address table 1 55 (process 237). If interrupt for the real 
time OS is caused, the interrupt handler 123 of the real 
time OS is actuated with reference to the interrupt 
25 address table 155, similarly (process 238). In general, 
when the task switching has to be performed by the 
interrupt process, the interrupt handlers 122 and 123 
call the re-schedulers 1 1 8 and 1 1 9 and do not return the 
control to the common interrupt handler 128. However, 
30 if task switching is not caused, the process of the inter- 
rupt handler is terminated. At this time, the interrupt 
handlers 122 and 123 return the control to the common 
interrupt handler 128. The common interrupt handler 
1 28 resumes operation from the process 239. The proc- 
35 ess 239 is the process for checking whether the operat- 
ing system is switched upon occurrence of interrupt. 
When the operating system is switched by the process 
235, the operating system has to be switched again to 
return to the original execution environment. Therefore, 
40 request is again made to the OS context switch module 
127 to execute the switching process (process 240). 
[0050] Fig. 1 6 shows a process flow of the interrupt 
handier of the real time OS as a part of the server side 
input and output device 222 called from the common 
45 interrupt handler 1 28. 

[0051] At first, the register in use is temporarily 
stored in the interrupt stack 1 53 (process 250). By mak- 
ing reference to the preferential interrupt table 156, 
judgment is made whether the input and output device 
50 Demanding interrupt is common tor a plurality of operat- 
ing systems (process 251 ). If not common, it is the inter- 
rupt demand for the real time OS to execute the 
corresponding interrupt process (process 253). If com- 
mon, reference is made to the preferential interrupt 
55 table 156 again to make judgment to which operating 
systems, the occurring interrupt demand corresponds 
(process 252). When the flag of the real time OS side is 
set or the common flag is not set, the interrupt process 
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for the real time OS interrupt is executed (process 253). 
When the flag of the general purpose OS side is set, the 
interrupt process for the general purpose OS interrupt is 
executed (process 254). Here, the interrupt process 254 
in the general purpose OS interrupt notifies occurrence 5 
of interrupt to th client side interrupt handler 122 to 
generate software interrupt to the general purpose OS 
116. Furthermore, if necessary, information obtained 
through the software interrupt process is written in the 
common memory 125. It should be noted that the gen- 10 
erated software interrupt has to be provided lower pref- 
erential order than the interrupt process executed 
currently. In execution of the interrupt process for the 
general purpose OS interrupt, since judgment for task 
switching is not required for no influence to the real time 15 
OS at all, the process of the interrupt handler 123 is ter- 
minated. Therefore, the register value temporarily 
stored in the interrupt stack 153 is restored (process 
259), and the control is returned to the common inter- 
rupt handler (process 260). It should bejnotedjhat omit 
* trncrof the process 255 is for speTo1i^ ;s upr^ihe 
process, and no problem will be arisen even in opera- 
tion to execute the process 255. 

[0052] On the other hand, after execution of the 
interrupt process corresponding to the real time OS 25 
interrupt (process 253), judgment is made whether task 
switching is necessary or not (process 255). If task 
switching is necessary, process of the interrupt handler 
123 is terminated. Therefore, the register value tempo- 
rarily stored on the interrupt stack 1 51 is restored (proc- 30 
ess 259), and the control is returned to the common 
interrupt handler (process 260). When judgment is 
made that task switching is necessary, the register 
value temporarily stored on the interrupt stack 151 is 
copied in the task management table (process 256), 35 
and the temporarily stored register on the interrupt stack 
is abandoned (process 257). Thereafter, the re-sched- 
uler 119 is actuated (process 258). It should be noted 
that if the processor 100 is provided with a function to 
increase and decrease the value of the interrupt stack 40 
pointer 1 58 in conjunction with making reference to data 
on the memory, the processes 256 and 257 may be exe- 
cuted in a lump. 

[0053] On the other hand, the interrupt handler 1 22 
of the general purpose OS actuated by the software 45 
interrupt generated by the interrupt handler 123, exe- 
cutes the process of the same content as the operation 
flow with reference to Fig. 10 in most part. It should be 
noted that what is partially differentiated is execution of 
the interrupt process corresponding to interrupt shown so 
in the process 181. Information obtained therein is writ- 
ten in the common memory 125. Accordingly, the proc- 
ess 181 in the interrupt handler 122 read out the 
information stored in the common memory 125 to oper- 
ate to execution of the process corresponding to the 55 
interrupt to realize the interrupt process without dir ctly 
accessing the input and output device. 
[0054] On the other hand, even when the client- 



server model discussed in connection with Fig. 14 is 
applied and the input and output device is in common 
for a plurality of operating systems, similarly to the dis- 
cussion given for Figs. 11 to 13, it can occur a case 
where judgment cannot be made with which operating 
system the interrupt process is to be executed unless 
content of interrupt is checked. The process flow of the 
interrupt handler 1 23 provided in the real time OS 1 1 7 in 
this case will be discussed with reference to Fig. 17. It 
should be noted that the table for making judgment of 
the content of interrupt is established under the premise 
where the switch table 200 is used in similar manner as 
that discussed above, the process discussed herein is 
applicable not only for the switch but also for other input 
and output device. 

[0055] At first, the register in use is temporarily 
stored in the interrupt stack 1 53 (process 270). By mak- 
ing reference to the preferential interrupt table 156, 
judgment is made whether the input and output device 
'andmg jn^ pJufalrty-of operat- 

ing systems (process 271 ). If not common, it is the inter- 
rupt demand for the real time OS to execute the 
corresponding interrupt process (process 274). If com- 
mon flag is set, the interrupt objective operating system 
is judged by making judgment of the content of interrupt 
(process 272). Comparing the content of interrupt and 
the switch table 200, when judgment is made that the 
dedicated switch for the real time OS is depressed, the 
real time OS 1 17 is stored as the interrupt objective OS, 
and when judgment is made that the dedicated switch 
for the general purpose OS is depressed, the general 
purpose OS 1 16 is stored as the interrupt objective OS. 
On the other hand, when judgment is made that the 
common switch is depressed, reference is made to the 
preferential interrupt table 156, the operating system, 
for which the flag is set, is stored as the interrupt objec- 
tive OS. Here, considering the case where the stored 
values in the preferential interrupt table 156 of Fig. 7 
and the switch table 200 of Fig. 12 are used, and IRQ#2 
is assigned to switch interrupt, when the switch #0 is 
input, reference is made to the real time OS, when the 
switch #2 is input, reference is made to the general pur- 
pose OS, and when the switch #3 is input, since the 
switch is for common use, reference is made to the pref- 
erential interrupt table 1 56 again to attain the interrupt 
objective operating system, such as the real time OS. 
[0056] Next, with reference to the interrupt objective 
OS (process 273), if it is the real time OS 1 17, the inter- 
rupt process lor the real time OS interrupt is executed 
(process 274). If it is the general purpose OS 116, the 
interrupt process 274 for the general purpose OS inter- 
rupt is executed (process 275). Here, the interrupt proc- 
ess 275 for the general purpose OS interrupt generates 
software interrupt for the general purpose OS 116 in 
order to notify the occurrence of interrupt to the client 
side interrupt handler 122. Furthermore, if necessary, 
information obtained through the software interrupt is 
written in the common memory 125. It should be appre- 
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ciated that the generated software interrupt has to be 
provided lower preferential order than the interrupt proc- 
ess in execution. 

[0057] In interrupt process execution corresponding 
to the general purpose OS interrupt, judgment of task 
switching is not necessary for not influencing to the real 
time OS at all. Accordingly, the process of the interrupt 
handler is terminated. Then, the register value tempo- 
rarily stored in on the interrupt stack 153 is restored 
(process 280), and the control is returned to the com- 
mon interrupt handler (process 281 ). It should be appre- 
ciated that omitting of the process 276 is for speeding 
up of the process, and no problem will be arisen even in 
operation to execute the process 276. 
[0058] On the other hand, after execution of the 
interrupt process corresponding to the real time OS 
interrupt, judgment is made whether task switching is 
necessary or not (process 276). If task switching is nec- 
essary, process of the interrupt handler 123 is termi- 
nated. Therefore, the register value temporarily stored 
oh the interrupt stack 1 53 is resfSrea (pr6^ss'2OT)Tartd 
the control is returned to the common interrupt handler 
(process 281). When judgment is made that task 
switching is necessary, the register value temporarily 
stored on the interrupt stack 151 is copied in the task 
management table (process 277), and the temporarily 
stored register on the interrupt stack is abandoned 
(process 278). Thereafter, the re-scheduler 1 19 is actu- 
ated (process 279). 

[0059] As set forth above, the method to apply the 
cli nt-server model as the method for using the same 
input and output device in common for a plurality of 
operating systems, has been discussed. Here, while 
discussion has been given for a method to notify the 
occurrence of interrupt from the server side operating 
system to other operating system by software interrupt, 
if some communication means is provided, it becomes 
possible to notify occurrence of interrupt from the server 
side input and output process 222 to the client side input 
and output process 221 . It can be replaced for the soft- 
ware interrupt set forth above. In the shown embodi- 
ment, in order to establish communication between two 
operating systems, the inter-OS communication func- 
tion 126 as shown in Fig. 1 is provided. Therefore, a 
method for making the input and output device common 
for a plurality of operating systems will be discussed 
with reference to Fig. 18. 

[0060] Most of Components in Fig. 1 8 are the same 
as components discussed in connection with Figs. 1 
and 5, but are differentiated in a virtual input and output 
driver 290 and a virtual interrupt handler 291 are pro- 
vided in place of the input and output driver 1 20 and the 
interrupt handler 122 provided in the general purpose 
OS 1 16. The virtual input and output driver 290 provides 
an interface for accessing the input and output device 
from an application task but does not directly read and 
write the input and output device and directly control the 
input and output device. Here, using the message com- 



munication provided by the inter-OS communication 
function 126, r ading and writing and control are 
requested to the input and output driver 121. Also, the 
result is also received from the input and output driver 
5 121 using the messag communication. The virtual 
interrupt handler 291 is actuated by the message trans- 
mitted from the interrupt handler 123 to execute the 
interrupt process. 

[0061] Next, flow of the process upon occurrence of 
10 the interrupt demand for the input and output device 
common for both of the operating systems will be dis- 
cussed with reference to Fig. 18. For convenience of 
illustration, in the preferential interrupt table of the inter- 
rupt number generated by the input and output device 
15 handled herein, the common flag 1 is set, and also, the 
flag is set on the side of the general purpose OS. 
[0062] The interrupt demand generated by the input 
and output device is once trapped in the common inter- 
rupt handler 128. The process is executed according to 
20 the flow of Fig. 15. Here, since it is assumed that it is 
interrupt from theTri put and output deviceln common for 
both of the operating systems, the interrupt handler 123 
provided in the real time OS is actuated. The interrupt 
handler 123 executes the process according to the flow 
25 discussed in connection with Fig. 16. Here, since it is 
assumed that common flag is set in the preferential 
interrupt table 156 and flag is set in the general purpose 
OS, the interrupt process 254 corresponding to the gen- 
eral purpose OS interrupt is executed. Here, the inter- 
ne rupt process 254 for the general purpose OS interrupt 
transmit the message to the virtual interrupt handler 291 
on the client side using the inter-OS communication 
function in order to notify occurrence of interrupt to the 
virtual interrupt handler 281 on the client side. It should 
35 be noted that information obtained through the interrupt 
process may be transmitted with attaching to the mes- 
sage, and may transmit information by writing in the 
common memory 1 25 and making reference to from the 
virtual interrupt handler 291 . Furthermore, when a mes- 
40 sage queue for receiving the message is not provided in 
the virtual interrupt handler 291, the message is trans- 
mitted once to the server task 1 1 2 provided as the appli- 
cation task and the virtual interrupt handler 291 is called 
from the server task 1 12 for actuating the virtual inter- 
45 rupt handler 291 . The virtual interrupt handier 291 exe- 
cutes the interrupt process by making reference to the 
result of process of the interrupt process attached to the 
message or the common memory 125 . 
T0063] Furthermore, the flow of process for execut- 
50 ing the input and output process requested trom the 
task provided in the general purpose OS will be dis- 
cussed with reference to Fig. 19. The virtual input and 
output driver 290 in the general purpose OS is only 
interface for accessing the input and output device from 
55 the office work IS, and requested input and output proc- 
ess is transferred to the input and output driver 121 
using the inter-OS communication function 126. It 
should be noted that the information obtained by the vir- 
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tual input and output driver 290 may be transmitted with 
attaching to the message, and also may be written in 
the common memory 125 and made reference to from 
the input and output driver 121 for transferring informa- 
tion. Furthermore, when the message queue for receiv- 5 
ing the message is not provided in the input and output 
driver 121, the message is transmitted once to the 
server task 113 provided in the appiication task to actu- 
ate the input and output driver 121 by calling the input 
and output driver 121 from the server task 113. The 10 
input and output driver 121 executed the input and out- 
put process by making reference to the content of 
request attached to the message or the common mem- 
ory 125. 

[0064] Next, flow of re-writing of the preferential 15 
interrupt table provided in the inter-OS control function 
124 will be discussed with reference to Fig. 20. The 
preferential interrupt table 156 is re-written by the man- 
agement task 115 managing the user demand or so 
forth. However, it is possible to cause mismatching^ 20 
when the interrupt process " 

erential interrupt table during re-writing of the preferen- 
tial interrupt table 156. Therefore, initially, all interrupt 
demand is masked so as not to cause any interrupt 
(process 301). ft should be appreciated that it is also 25 
possible to mask only interrupt demand for the interrupt 
number for which re-writing is to be effected. After set- 
ting the interrupt mask, the content of the preferential 
interrupt table 156 is updated (process 302) and then 
the set interrupt mask is released (process 303) to per- 30 
mit re-writing of the preferential interrupt table 156. 
[0065] As set forth above, the method to make the 
input and output device common for a plurality operating 
systems has been discussed, an example of application 
of the present invention for a graphic display of a built-in 35 
equipment having a user interface, such as a vehicle 
mounted navigation system, as practical application, 
will be discussed with reference to Fig. 21. It should be 
noted that the operating system operated on the graphic 
display systems are the general purpose OS 116 and 40 
the real time OS 117 similarly to Fig. 1, and a 
task/thread operating on the real time OS is assumed to 
have higher preferential order than a task/thread operat- 
ing on the general purpose OS. 

[0066] The graphic display device has graphic driv- as 
ers 310 and 312 parsing command for drawing and dis- 
playing and controlling a graphic hardware 314, graphic 
interrupt handlers 311 and 313 to be actuated by the 
interrupt demand generated by. the graphics hardware, 
and the graphic hardware 314 displaying an image data so 
developed to the pixels. The graphic hardware 314 has 
a frame memory 316 storing luminance value of each 
pixel and display control 315 taking out the luminance 
value of each pixel from the frame memory 316 per ver- 
tical synchronization frequ ncy to output to the display 55 
104. Here f in the frame memory, conflict of resource is 
avoided by making the a drawing region 317 for general 
purpose OS storing image generated by the graphic 



driver 310 of the general purpose OS and a drawing 
region 31 8 for the real time OS storing image generated 
by a graphic f¥driver 312 of the real time OS independ- 
ent or separated. By this, upon switching of the operat- 
ing system, respective drawn image are stored. Even 
when the operating system is switched again, the proc- 
ess can be continued from the condition before switch- 
ing. On the other hand, it is assumed that the graphic 
driver 312 and the graphic interrupt handler 313 pro- 
vided in the real time OS operate as server, and the 
graphic driver 310 and the graphic interrupt handler 31 1 
provided in the general purpose OS operate as client. 
[0067] Operational flow in drawing and display 
demand from the application task incorporated in the 
real time OS will be discussed at first. The application 
task calls the drawing command provided in the graphic 
driver 312 to execute the drawing process. The drawing 
command is consisted of command for drawing line or 
polygon and commands designating attribute, such as 
, JLne. w]o1rj^lQtt graphic driver 312 

parses the drawing command to develop the pixels in 
the drawing region 318 for the real time OS. If the 
graphic hardware 314 includes an acceleration function 
executing developing the pixels by hardware, such func- 
tion may be used. When drawing is completed, then, the 
display command provided in the graphic driver 312 is 
executed. The display command is consisted of a dis- 
play start address in the frame memory 316 and a com- 
mand designating a display size to display the image 
designated by controlling the register in the display con- 
trol 315. When the displaying of the designated image is 
started, the display control generates an interrupt 
demand. The interrupt demand is once trapped in the 
common interrupt handler 128, and instantly judged as 
the interrupt demand from the common device to call 
the graphic interrupt handler 313. By this, the graphic 
interrupt handler 313 detects that the image is dis- 
played. 

[0068] Next, operational flow in the drawing and dis- 
playing demand from the application task incorporated 
in the general purpose OS 1 16 will be discussed. The 
application task calls drawing command provided in the 
graphic driver 310 to develop the pixels in the drawing 
region 317 for the general purpose OS. When drawing 
is completed, then, the display command provided in 
the graphic driver 310 is executed. The display com- 
mand transfers message designating the display start 
address and the display size in the frame memory 316 
to the graphic driver 312 using the inter-OS communica- 
tion function 126. The graphic driver 312 receiving the 
demand, displays the designated image by controlling 
the register in the display control 315. It should be noted 
that the graphic driver 312 makes judgment display 
demand from which operating systems has higher pref- 
erence, to constantly display the frame memory to be 
preferentially displayed. When displaying of the desig- 
nated image is started, the display control 315 gener- 
ates the interrupt demand. The interrupt demand is 
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once trapped by th common interrupt handler 1 28, and 
instantly judged as interrupt demand from the common 
devic to actuat the graphic interrupt handier 313. The 
graphic interrupt handler 313 transfers the received 
interrupt demand to the graphic interrupt handler 31 1 
using the inter-OS communication function 126. By this, 
the graphic interrupt handler 31 1 detects that the image 
is displayed. 

[0069] The particular embodiment of the graphic 
display system, to which the present invention has been 
discussed hereinabove, various peripheral devices, 
such as serial/network communication, CD-ROM/DVD- 
ROM storage device, can be made common for a plural- 
ity of operating systems by application of the present 
invention. 

[0070] According to the present invention, in the 
computer system operating a plurality of operating sys- 
tems with the single processor, the same input and out- 
put device can be used in common from the application 
tasks executed by respective operating systems to per- 
mit- reduction, of total number ot-the^ut-an^output , 
devices. Furthermore, according to the present inven- 
tion, the input and output device common for a plurality 
of operating systems and the input and output driver for 
data input and output, and the interrupt handler are 
loaded in one operating system, and by requesting input 
and output process to the input and output driver and 
the interrupt handler from the other operating system, 
the input and output process can be continued without 
resetting the input and output device to improve opera- 
bility. 

[0071] Although the present invention has been 
illustrated and described with respect to exemplary 
embodiment thereof, it should be understood by those 
skilled in the art that the foregoing and various other 
changes, omission and additions may be made therein 
and thereto, without departing from the spirit and scope 
of the present invention. Therefore, the present inven- 
tion should not be understood as limited to the specific 
embodiment set out above but to include all possible 
embodiments which can be embodied within a scope 
encompassed and equivalent thereof with respect to the 
feature set out in the appended claims. 

Claims 



1 . A computer system comprising : 

a plurality of operating systems; and 
OS switching means for switching a plurality of 
operating systems, said OS switching means 
making reference to a preferential interrupt 
table on the basis of an interrupt factor for 
switching to corresponding operating system 
and calls interrupt processing means incorpo- 
rated in said operating system. 

2. A computer system as set forth in claim 1 , 



wherein said preferential interrupt table 
stores whether the interrupt is from a peripheral 
device common in a plurality of operating systems 
or not in addition to the operating systems to be 
5 actuated per interrupt factor. 

3. A computer system as set forth in claim 2, 

the OS switching means makes reference to 
10 the preferential interrupt table on the basis of 

interrupt factor, makes judgment whether the 
interrupt demand is for interrupt common for a 
plurality of operating systems, determines 
operating system to be objective for interrupt by 
is parsing the content of the peripheral device 

generating interrupt as judged to be common 
interrupt, for switching the operating system, 
and in conjunction therewith for calling interrupt 
processing means provided in said operating 
20 system. 

4. A computer system comprising: 

a plurality of operating systems; 
25 OS switching means for switching a plurality of 

operating systems; 

peripheral device to be common for a plurality 
of operating systems; 

data inputting and outputting server for input- 
30 ting and outputting data with the peripheral 

device to be used in common, providing in one 
of the operating systems; and 
data inputting and outputting client for inputting 
and outputting data with the operating system 
35 other than said one operating system, request- 

ing inputting and outputting data to said data 
inputting and outputting server and executing 
inputting and outputting of data by receiving a 
result of data inputting and outputting with the 
40 peripheral server in the data inputting and out- 

putting server. 

5. A computer system as set forth in claim 4, 

45 which further comprises a preferential interrupt 

table storing operating system to be actuated 
per interrupt factor and preferential interrupt 
table re-writing means for re-writing the prefer- 
ential interrupt table. 
50 said OS switching means makes reference to 

the preferential interrupt table per interrupt fac- 
tor, makes judgment whether the interrupt 
demand is for interrupt to be common for a plu- 
rality of operating systems, and calls interrupt 
55 processing means included in said data input- 

ting and outputting server if judged as common 
interrupt. 
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6. A computer system as set forth in claim 4, wherein 

said data inputting and outputting server is pro- 
vided in a region managed by the operating 
system having the highest preferential order. 5 

7. A computer system as set forth in claim 4, 

which comprises inter-OS communication 
means for mutual communication between a w 
plurality of operating systems, 
said data inputting and outputting server and 
said data inputting client means are communi- 
cated. 

75 

8. A computer system as set forth in claim 5, wherein 

said data inputting and outputting server is pro- 
vided in a region managed by the operating 
system haying the^ 20 

9. A computer system as set forth in claim 5, 

which comprises inter-OS communication 
means for mutual communication between a 25 
plurality of operating systems, 
said data inputting and outputting server and 
said data inputting client means are communi- 
cated. 

30 



35 



40 



45 



50 



55 



15 



EP 1 054 322 A2 



1 



FIG. 1 



101 



MEMORY 



110 



TASK A 



111 



TASK B 



112 



SERVER 
TASK 



113 



SERVER 
TASK 



TASK C 



114 115 
GEMENT 



TASK 



OFFICE WORD OS 



RE- 
SCHEDULER 



INPUT/OUTPUT 
DRIVER 



INTERRUPT 
HANDLER 



118 



120 



122 



116 



JL 



127 



REAL TIME OS 



RE- 
SCHEDULER 



INPUT/OUTPUT 
DRIVER 



INTERRUPT 
HANDLER 



119 



121 



123 



117 



JL 



125 



COMMON 
MEMORY 



INTER-OS CONTROL FUNCTION 
^126 ^127 ^128 



INTER-OS 
COMMUNICATION 
FUNCTION 



OS CONTEXT 
SWITCHING 



COMMON 
INTERRUPT 
HANDLER 



JL 



129 



INTERRUPT 
MANAGEMENT 
TABLE 



00 



PROCESSOR 
107 



TIMER 
DEVICE 



108 



INTERRUPT 
SIGNAL 

LINE 



102 



INPUT/OUTPUT 
CONTROL UNIT 



PROCESSOR BUS 
104 




SENSOR 



09 



NETWORK 



16 



EP 1 054 322 A2 



FIG. 2 



101 




PROCESSOR BUS ^ 



103 



PROCESSOR 



130 



CACHE 
MEMORY 



CPU 



131 



^13 2 



_ GENERAL _J 

PURPOSE 
I — REGISTER — | 



PC 



133 



SR 



134 
— K- 



135^ 
DATA BUS 



100 



138 



INTERRUPT 
CONTROLLER 


> 


107 



137 



TIMER 
DEVICE 



_z 136 
ADDRESS BUS 



108 



INTERRUPT 
SIGNAL 
LINE 



102 



17 



EP 1 054 322 A2 



FIG. 3 



31 , 


. /140 




3 2 10^. 
1 I I T 


BL 
Lj-J 


OTHER STATUS 


LVL 
i . i l 1 



INTERRUPT BLOCK BIT ~ INTERRUPT MASK imr-— 



31 



140 



BL 
-t" 



FIG.4 



OTHER STATUS 



142 



INTERRUPT BLOCK BIT 



M31 




M2 


M1 


MO I 




c 



INTERRUPT MASK BIT 



146 145 144 



18 



EP 1 054 322 A2 



FIG. 5 



116 



117 



OFFICE WORK OS 



118 



RE-SCHEDULER 



122 



INTERRUPT HANDLER 


^150 


_^151 




INTERRUPT 




INTERRUPT 






STACK 




STACK 






POINTER 




POINTER 









OFFICE WORK OS 



119 



RE-SCHEDULER 



.123-.. 



INTERRUPT HANDLER 

.152 ^153 



INTERRUPT 
STACK 
POINTER 



INTERRUPT 
STACK 
POINTER 



JL 



124 



INTER-OS 
CONTROL 
UNCTION 



128 



127 



COMMON INTERRUPT HANDLER 

154 



EXECUTING OD 
STORAGE 



129 



INTERRUPT MANAGEMENT 



TABLE 



155 



INTERRUPT ADDRESS TABLE 



156 



PREFERENTIAL INTERRUPT 
TABLE 



OS CONTEXT SWITCHING 
^15 7 



STORED CONTEXT FOR 
OFFICE WARK OS 



JL 



158 



STORED CONTEXT FOR 
REAL TIME OS 



19 



EP 1 054 322 A2 



FIG. 6 



INTERRUPT ADDRESS TABLE 



INTERRUPT 
NUMBER 


INTERRUPT START ADDRESS 


OFFICE WORK OS 


REAL TIME OS 


IRQO 


0x00000400 


0x00000600 


IRQ1 


0x00000420 


0x00000620 


IRQ 2 


0x00000440 


0x00000640 


IRQ 3 


0x00000480 


0x00000680 


IRQ 4 


0x000004 AO 


0x000006A0 








IRQ 15 


OX000005CO 


0x00000700 



FIG. 7 



PREFERENTIAL INTERRUPT TABLE 

.156 



INTERRUPT 
NUMBER 


OFFICE 
WORK OS 


REAL TIME OS 


COMMON 


IRQO 


0 


1 


0 


IRQ 1 


1 


0 


0 


IRQ 2 


0 


1 


1 


IRQ 3 


1 


0 


1 


IRQ 4 


0 


1 


0 




• 






IRQ 15 


0 


1 


0 



20 



EP 1 054 322 A2 



FIG. 8 



127 



(OS CONTEXT SWITCHING^ 




REAL TIME OS— OFFICE WORK OS 



OFFICE WORK OS-*REAL TIME OS 
.161 



SAVE REGISTER 


! IN STORED 




SAVE REGISTER 


! IN STORED 


CONTEXT FOR OFFICE WORK OS 




CONTEXT FOR REAL TIME OS 






162 






RECOVER REGISTER FROM STORED 




RECOVER REGISTER FROM STORED 


CONTEXT FOR REAL TIME OS 




CONTEXT FOR OFFICE WORK OS 




< 












165 







163 



164 



WRITE OS AFTER SWITCHING 
IN EXECUTING OS STORAGE 
PARAMETER 



c 



END 



21 



EP 1 054 322 A2 



FIG. 9 



128 



(COMMON INTERRUPT HANDLER) 



170 



TAKE OUT KIND OF OS DURING 
EXECUTION FROM EXECUTING OS 
STORAGE PARAMETER 



171 



CHECK IN WHICH OS 
INTERRUPTION IS CAUSED 




INTERRUPT OBJECT I VEJJS. 

EXECUTING OS 



!=EXECUTING OS 



1 



173 



REQUEST SAVING AND 
RESTORING TO OS CONTEXT 
SWITCHING MODULE 




174 



OFFICE WORK OS 



EXECUTE INTERRUPT HANDLER 
OF OFFICE WORK OS 



s 

_/175 




■J 


EXECUTE INTERRUPT HANDLER 
OF REAL TIME OS 



176 



177 




178 



c 



REQUEST SAVING AND 
RESTORING TO OS CONTEXT 
SWITCHING MODULE 



END 



22 



EP 1 054 322 A2 



FIG. 10 



122 



( INTERRUPT HANDLER) 



180 



SAVE REGISTER IN USE 
IN INTERRUPT STACK 



181 



EXECUTE INTERRUPT PROCESS 
CORRESPONDING TO INTERRUPT 




186 



COPY REGISTER ON INTERRUPT 
STACK TO TASK MANAGEMENT 
TABLE 



187 



ABANDON REGISTER OF SAVED 
INTERRUPT STACK 



188 



EXECUTE RE-SCHEDULING 
FROM BEGINNING 



c 



END 



7 r . -r*~- 



1 



184 



RECOVER REGISTER IN USE 
FROM INTERRUPT STACK 



185 



RETURN CONTROL TO COMMON 
INTERRUPT HANDLER 



23 



EP 1 054 322 A2 



FIG. 11 



DEDICATED SWITCH DEDICATED SWITCH 

FOR REAL TIME OS DISPLAY 104 FOR OFFICE WORK OS 




COMION SWITCH 



FIG. 12 

SWITCH TABLE ^200 



SWITCH NUMBER 


ATTRIBUTE 


#0 


RIAL TIME OS 


#1 


RIAL TIME OS 


#2 


OFFICE WORK OS 


#3 


COMMON 


#4 


COMMON 






#n 


COMMON 



24 



EP 1 054 322 A2 



FIG. 13 



128 



( COMMON INTERRUPT HANDLER) 

| ^210 



TAKE OUT KIND OF OS DURING 
EXECUTION FROM EXECUTING OS 
STORAGE PARAMETER 




YES 



CHECK IN WHICH OS 
INTERRUPTION IS CAUSED 




✓ 212 








JUDGE CONTENT OF INTERRUPT 
AND CHECK KIND OF OS 



213 



214 

•^EXECUTING OS 



,215 



==EXECUTING OS 
< 



REQUEST SAVING AND 
RESTORING TO OS CONTEXT 
SWITCHING MODULE 



216 



INTERRUPT OBJECTIVE OS. 
OFFICE WORKCr 



REAL TIME OS 



217 



EXECUTE INTERRUPT HANDLER 
OF OFFICE WORK OS 



,218 



EXECUTE INTERRUPT HANDLER 
OF REAL TIME OS 




220 



REQUEST SAVING AND 
RESTORING TO OS CONTEXT 
SWITCHING MODULE 



25 



EP 1 054 322 A2 



FIG. 14 



OFFICE WORK OS 



116 



221 



CLIENT SIDE INPUT/ 


OUTPUT PROCESS 






__^120 




INPUT/OUTPUT 






DRIVER 






.122 

' — ' 




INTERRUPT 






HANDLER 











223 



REQUEST 
PROCESS 



<5 



224 



REPLY RESULT 



^1 



117 



REAL TIME OS 



222 



SERVER SIDE INPUT/ 
OUTPUT PROCESS 



INPUT/OUTPUT 
DRIVER 



123 



INTERRUPT 
HANDLER 



DATA INPUT/OUTPUT 



225 



124 



INTER-OS CONTROL FUNCTION 



125 



COMMON 
MEMORY 



126 



INTER-OS 

COMMUNICATION 

FUNCTION 



127 



OS CONTEXT 
SWITCHING 



128 



129 



COMMON 




INTERRUPT 


INTERRUPT 




MANAGEMENT 


HANDLER 




TABLE 



226 



INPUT/OUTPUT UNIT 



<^DI SPLAY j~- 104 




SENSOR 



105 



106 



26 



EP 1 054 322 A2 



FIG. 15 



128 



(COMMON INTERRUPT HANDLER) 



230 



TAKE OUT KIND OF OS DURING 
EXECUTION FROM EXECUTING OS 
STORAGE PARAMETER 




YES 



CHECK IN WHICH OS 
INTERRUPTION IS CAUSED 




- "Jf.3*.-«:- i-Mss 

,232 








SET REAL TIME OS AS 
INTERRUPT OBJECTIVE OS 



234 

!=EXECUTING OS 



==EXECUTING OS 
< 



REQUEST SAVING AND 
RESTORING TO OS CONTEXT 
SWITCHING MODULE 



236 




REAL TIME OS 



AFTER OS SWITCHING? 
NO 

END 



REQUEST SAVING AND 
RESTORING TO OS CONTEXT 
SWITCHING MODULE 



233 



235 



OFFICE WORK 0S7 ^ 


,237 






EXECUTE INTERRUPT HANDLER 
OF OFFICE WORK OS 




EXECUTE INTERRUPT HANDLER 
OF REAL TIME OS 


\< 




I 


^ — ,239 









238 



240 



27 



EP 1 054 322 A2 



FIG. 16 



( INTERRUPT HANDLER) 



123 



250 



SAVE REGISTER IN USE 
TO INTERRUPT STACK 




REAL TIME OS 




253 OFFICE WORK OS 



254 



EXECUTE INTERRUPT PROCESS 
CORRESPONDING TO REAL 
TIME OS INTERRUPT 



EXECUTE INTERRUPT PROCESS 
CORRESPONDING TO OFFICE 
WORK OS INTERRUPT 




COPY REGISTER ON 
INTERRUPT STACK TO 
TASK MANAGEMENT TABLE 



ABANDON REGISTER OF 
SAVED INTERRUPT STACK 



256 



257 



258 



RECOVER REG I 
FROM INTERRU 


STER IN USE 
PT STACK 




RETURN CONTR( 
INTERRUPT HAf 


)L TO COMMON 
IDLER 



259 



260 



EXECUTE RE-SCHEDULING 
FROM BEGINNING 



c 



END 



3 



28 



EP 1 054 322 A2 



FIG. 17 



( INTERRUPT HANDLER) 



123 



270 



SAVE REGISTER IN USE 
TO INTERRUPT STACK 




272 



JUDGE INTERRUPT CONTENT 
AND CHECK KIND OF OS 



EXECUTE INTERRUPT 
CORRESPOND IN 
TIME OS INTERRUPT 



REAL TIME OS 



274 



PROCESS 
G TO REAL 





OFFICE WORK OS 



275 



EXECUTE INTERRUPT PROCESS 
CORRESPONDING TO OFFICE 
WORK OS INTERRUPT 



276 

TASK SWITCHING^ — ^ MO 



COPY REGISTER ON 
INTERRUPT STACK TO 
TASK MANAGEMENT TABLE 



ABANDON REGISTER OF 
SAVED INTERRUPT STACK 



277 



278 



279 



RECOVER REGISTER IN USE 
FROM INTERRUPT STACK 



280 



281 



RETURN CONTROL TO COMMON 
INTERRUPT HANDLER 



EXECUTE RE-SCHEDULING 
FROM BEGINNING 



C 



END 



29 



EP 1 054 322 A2 



FIG. 18 



112 



111 



110 



113 



114 



115 



SERVER 
TASK 


TASK A 


TASK 8 





116 



OFFICE WORD OS 



290 



VIRTUAL INPUT/ 
OUTPUT DRIVER 



291 



VIRTUAL INTERRUPT 
HANDLER 



SERVER 
TASK 


TASK C 


MANAGEMENT 
TASK 





117 



OFFICE WORD OS 




^,290 




VIRTUAL INPUT/ 






OUTPUT DRIVER 




^291 




VIRTUAL INTERRUPT 






HANDLER 









f 



inter-os 

COMMUNICATION 
FUNCTION 



1; > R INTER-OS CONTROL 
lze FUNCTION 



,127 



OS CONTEXT SWITCHING 

,157 



STORED CONTEXT 
FOR OFFICE 
WORK OS 



158 



STORED 
CONTEXT FOR 
REAL TIME OS 



124 



,128 



COMMON INTERRUPT HANDLER 

✓154 



EXECUTING OS 
STORAGE 



T 



129 



INTERRUPT MANAGEMENT 
TABLE , 155 



INTERRUPT ADDRESS TABLE 



156 



PREFERENTIAL INTERRUPT 
TABLE 



30 



EP 1 054 322 A2 



FIG. 19 



112 



111 



110 



SERVER 
TASK 


TASK A 


TASK B 





113 



114 



115 



OFFICE WORD 
OS 



116 



290 



VIRTUAL INPUT/ 
OUTPUT DRI VER 



291 



VIRTUAL INTERRUPT 
HANDLER 



1 



SERVER 
TASK 


TASK C 


MANAGEMENT 
TASK 





OFFICE WORD OS 



VIRTUAL INPUT/ 
OUTPUT DRIVER 



,121 



.123 



VIRTUAL INTERRUPT 
HANDLER 



INTER-OS 
COMMUNICATION 
FUNCTION 



126 INTER-OS CONTROL 
1Zb FUNCTION 



127 



OS CONTEXT SWITCHING 

,157 



STORED CONTEXT 
FOR OFFICE 
WORK OS 



158 



STORED 
CONTEXT FOR 
REAL TIME OS 



124 



COMMON INTERRUPT HANDLER 




EXECUTING OS 
STORAGE 


^_/154 





129 



INTERRUPT MANAGEMENT 



TABLE 



155 



INTERRUPT ADDRESS TABLE 



156 



PREFERENTIAL INTERRUPT 
TABLE 



117 



31 



EP 1 054 322 A2 



FIG. 20 



REWRITE PREFERENTIAL 
INTERRUPT TABLE 



.300 

my 



MASK ALL INTERRUPT DEMAND 






REWRITE CONTENT OF 
PREFERENTIAL 
INTERRUPT TABLE 






RELEASE W 
INTERRUPT 


ISK FOR ALL 
DEMAND 



301 



302 



303 



32 



EP 1 054 322 A2 



FIG. 21 



/1 12 



/I11 



,110 



SERVER 
TASK 


TASK A 


TASK B 





OFFICE WORD OS 
cL 



310 



GRAPHIC DRIVER 



311 



GRAPHIC 

INTERRUPT 

HANDLER 



116 



SERVER 
TASK 


TASK C 


MANAGEMENT 
TASK 





OFFICE WORD OS 



312 



GRAPHIC DRIVER 



313 



GRAPHIC 

INTERRUPT 

HANDLER 



117 



125 



COMMON 
MEMORY 



126 



INTER-OS 

COMMUNICATION 

FUNCTION 



127 



OS CONTEXT 
SWITCHING 



128 



COMMON 

INTERRUPT 

HANDLER 



129 



INTERRUPT 

MANAGEMENT 

TABLE 



INTER-OS 

CONTROL 

FUNCTION 



124 



GRAPHIC HARDWARE 



315 



DISPLAY 
CONTROL 



316 



^317 



FRAME MEMORY 



DRAWING REGION 
FOR OFFICE 
WARK OS 



318 



DRAWING 
REGION FOR 
REAL TIME OS 



314 



33 




THIS PAGE BLANK (uspto) 



